chore: bump java-bigtable to 2.85.0, beam to 2.77.0, emulator to 0.222.0 - #4640

- java-bigtable: 2.81.0 → 2.85.0
- google-cloud-bigtable-emulator: 0.218.0 → 0.222.0
- beam: 2.72.0 → 2.77.0
- conscrypt: 2.6.0 → 2.6.2 (to match bigtable 2.85.0 deps-bom)
- maven.compiler.source/target: 1.8 → 11 (beam 2.77+ requires Java 11)

Add dev.cel relocation to 1.x-shaded and 2.x-shaded: bigtable 2.85.0
pulls in grpc-xds which transitively introduces dev.cel:0.13.0; without
relocation those classes leak un-relocated into the shaded jars and
trip verify-shaded-jar-entries.

Upgrade kokoro java8 CI jobs to use the java11 docker image (presubmit,
continuous, nightly). Move bigtable-dataflow-parent into a JDK-activated
profile so it is excluded from any remaining Java 8 build environments.

Change-Id: I558368876e3e46827097598f426abc8469e503cf

Replication endpoint tests (TestUtils, shared by 1.x and 2.x):

- waitForReplication polled 5 times with a doubling sleep, but the final
  8s sleep was not followed by another check, so the effective budget was
  7.5s and a failure cost 8s of dead time. Replace it with a deadline
  based poll (60s, every 500ms) that always re-checks after sleeping.
- The replicated-entry counter is static and shared by every test in the
  class. Resetting it in @before is not enough because replication is
  asynchronous: entries still in flight from the previous test arrive
  after the reset and count towards the next test's target. This is worst
  after the 10k-row test. Drain replication before resetting the counter,
  and retry the table comparison in assertTableEventuallyEquals so the
  assertion waits on the replicated data rather than the counter.
- Close the ResultScanners in assertTableEquals; they were leaked, which
  matters now that the comparison runs in a retry loop.

TestBufferedMutator:

- testAutoFlushOff/testAutoFlushOn write on one Connection and read back
  on another, asserting on the first response. flush() makes the write
  durable but does not guarantee a read on a separate connection observes
  it immediately, so the read could return 0 cells. Retry the read; it
  only absorbs that delay and still fails if the write never appears.
- Close the ResultScanner in testBulkMutation.

Change-Id: I5a1936b0037965f6306f545164c014a0a6306c3d

testModifyTable_HBase2_Async timed out waiting 60s on modifyTableAsync.
modifyTableAsync chains a plain thenApply off getDescriptor, and because
ApiFutureUtils completes its futures with a directExecutor, that
continuation runs on a gRPC callback thread -- where it then blocks on
the modifyFamilies RPC. With the suite running admin operations across
four classes in parallel these pile up and starve the callback pool, so
the call can take well over a minute. Raise the wait to 5 minutes; the
1800s fork timeout still bounds a genuine hang.

This only stops the test failing. The blocking continuation is still
there and can stall modifyTable/modifyTableAsync for callers.

Change-Id: Ibdd83e80ad47f429791d8e189dead12d2f96ec54